ci: version PR packages by commit and make the Octopus publish idempotent - #231
Merged
Merged
Conversation
NickJosevski
force-pushed
the
chore/idempotent-octopus-publish
branch
from
August 18, 2026 05:31
9c4164d to
bf78d0c
Compare
NickJosevski
marked this pull request as ready for review
August 19, 2026 02:16
NickJosevski
force-pushed
the
chore/idempotent-octopus-publish
branch
from
August 20, 2026 05:32
bf78d0c to
a816bdc
Compare
NickJosevski
enabled auto-merge (rebase)
August 20, 2026 05:32
NickJosevski
force-pushed
the
chore/idempotent-octopus-publish
branch
from
August 28, 2026 01:43
a816bdc to
b026c2d
Compare
YuKitsune
requested changes
Aug 28, 2026
Contributor
There was a problem hiding this comment.
This seems sketchy. You could end up in a scenario where you have 6.6.1-PullRequest0229.4 and 6.6.1-PullRequest0229.5, but .4 is actually the newest one. That's confusing.
I'd prefer to see a different versioning strategy for PR builds. Would it be viable to append the commit SHA to the version, rather than a commit count?
NickJosevski
changed the title
Both publish actions default to FailIfExists, so re-publishing a version that already exists fails the job. GitVersion derives a PR version from the commit count, so amending a commit or re-running a workflow reuses the version and the build information push then 409s. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
GitVersion numbers a PR build from the commit count, so amending a commit reuses the number and the publish fails on the package already in Octopus. Append the PR head SHA so every commit gets its own package, keeping the count in front of it - Octopus compares that identifier numerically, so the packages still rank in build order. Overwriting stays on for the one case a version can still repeat, building the same commit twice, where the artefacts being replaced are that commit's own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The publish job creates an Octopus release on every build, PR builds included, and does it after the package push. Overwriting the package therefore only gets a re-run of the same commit as far as this step, which then fails on the release that already carries that version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NickJosevski
force-pushed
the
chore/idempotent-octopus-publish
branch
from
August 28, 2026 07:05
da1067b to
1488710
Compare
Contributor
Author
|
ok now: |
Contributor
Author
|
@YuKitsune how does this look now? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Publish to Octopusfails whenever a version is published twice:GitVersion derives the PR version from the commit count (e.g.
6.6.1-PullRequest0229.4), so amending a commit or re-running the workflow produces the same version as the previous run, and both publish actions default toFailIfExists. Hit on #229 after a force push.Versioning. PR builds now carry the head SHA as a trailing identifier —
6.7.2-PullRequest0231.4.gb026c2d. The commit count stays in front of it so packages still sort in build order: Octopus compares that identifier numerically, ranking.10above.5rather than lexically below it. Thegprefix, as ingit describe, keeps the identifier alphanumeric — an all-digit SHA beginning with a zero would be an invalid SemVer numeric identifier. Onlypull_requestbuilds get the suffix; release, nightly and dispatch versions are unchanged.Overwriting. Kept, because a version can still repeat when the same commit is built twice — a workflow re-run, or a re-published release. It can no longer replace one commit's package with another's, so a lower build number can no longer be the newer artefact.
Release creation.
Create a releaseruns on PR builds too, after the package push, and fails on a version it has already made. Overwriting the package alone therefore only got a re-run as far as that step, so it now passesignore_existing: true.Checked against a local Octopus before pushing:
Octopus.TeamCity.6.6.1-PullRequest0229.4.g1a2b3c4.zipuploads and parses, the built-in feed ranks.10.gdeadbee > .5.gf00ba71 > .4.g1a2b3c4, and re-pushing an identical version still returns409 A package with the same name and version already exists— the caseoverwrite_modecovers../gradlew packageName -Pversion=6.7.2-PullRequest0231.4.gb026c2dnames the zip correctly.Conflicts with #223, which rewrites the same step for GitVersion 6; whichever lands second needs
GITVERSION_FULLSEMVERrenaming toGitVersion_FullSemVer.